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Implementing CRCs 



At an unrecorded event 
lost in the mists of time, 
a caveman named Og 
sent a message propos- 
ing peace, via smoke 
signal, to the signal officer of the neigh- 
boring tribe. Unfortunately, a gust of 
w ind disrupted the pattern of a particu- 
lar!) important part of the message, and 
the message was misunderstood. Sadly, 
Og"s tribe was wiped out. 

Ever since then, people have been 
sending messages by methods ranging 
from smoke signals to laser beams to 
spread-spectrum communications sat- 
ellites, and messages have been arriving 
garbled, with more or less disastrous re- 
sults. It's not surprising, then, that peo- 
ple have long sought ways to make sure 
that their messages were received prop- 
erly. Lots of methods have been tried 
over the years. 

Today, one of the most elective and 
popular error-detection methods is the 
cyclic redundancy check (CRC). It's 
used in virtually every field where trans- 
mitting serial data is involved. It's even 
built into your disk-drive controller. 
Most of you have already heard of the 
CRC , and you've almost certainly used 
it, whether you are aware of it or not. 

Though ubiquitious, the CRC algo- 
rithm is surrounded by an inordinate 
amount of fog. We can't even seem to 
agree on what the acronym stands for 
(some say it's cyclic redundancy code). 
Ask hardware people how it works, and 
they're likely to say, "It's done with shift 
registers and exclusive-OR gates." Ask 
mathematicians, and they'll say, "It's 
done using a polynomial division, mod- 
ulo two, with the generating polynomial 
chosen from a closed Galois field." (Oh. 
Thank you very much. That clears ev- 
erything right up.) Ask honest software 
types, and they'll tell you, "Search me 
how it works. I just copied it from the 
XMODEM code." 

In this article, I'm going to try to cut 
through some of that obscuring fog. 



Most of you have 
already heard of 
the CRC, and 
you've almost 
certainly used it, 
whether you are 
aware of it or not. 

We'll begin with some background as to 
the motivation and power of the CRC, 
then continue on to the gory details. I'll 
spend just enough time discussing poly- 
nomials to convince you that they're not 
needed, and then we'll get on to some 
efficient code implementations. I'll also 
discuss some of the gotchas you should 
beware of. 

With any kind of luck and some per- 
sistence on your part, you'll leave this 
article with a real understanding of how 
and why the CRC works. At the very 
least, you should be able to say, "Search 
me. I just copied it from Crenshaw." 

SOME BACKGROUND 

Ever since the landmark Og af- 
fair, people have been seeking 
ways to make sure that their 
messages get across without being mis- 
understood. In today's information age, 
that's more important than ever. We 
can accomplish this goal in many ways, 
but they all boil down to these three 
requirements: 

■ Along with the message, provide the 
recipient with some way to know if it got 
there correctly. 

■ The recipient should send a return 
message, acknowledging receipt or ask- 
ing for a retry. 
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■ Continue to send the message until it 
gets to its destination ungarbled. 

Effective data transmission involves 
two aspects: error detection and error 
transmission. The CRC is an error de- 
tection mechanism. Yes, I know that 
some error detection and correction 
methods such as the Hamming codes 
exist, but today, almost everyone still 
separates the two aspects and counts on 
retransmission for the correction half of 
the system. 

How can the recipient of a message 
tel 1 whether it's been garbled ? The most 
obvious way is to send every message 
twice. But that method involves a lot of 
overhead — at least double the trans- 
mission time; much more if the error 
rate is high enough so that errors are 
likely. And that's bad. Time is money. 

We can make things a little better by 
splitting the message up into smaller 
blocks, and seeking confirmation on 
each block. This way, we don't have to 
retransmit the whole message, but only 
the blocks that were garbled. But we're 
still limited to a minimum of twice the 
transmission time. What we really need 
is a method to test the message for cor- 
rectness, without using many bits of the 
message. 

Of course, the ancient kings knew 
how to authenticate messages. They 
used a courier and sealed the messages 
with their private seal, carefully mono- 
grammed to discourage forgery. No one 
could tamper with the message without 
breaking the seal. We can't do that with 
messages that are sent electronically, 
but we can steal the general idea. You 
append some kind of code to the mes- 
sage that's virtually certain to be al- 
tered if the message is tampered with or 
otherwise garbled. 

Early on, someone got the idea to use 
a code (sometimes called the block- 
check code, or BCC) that could some- 
how be computed from the body of the 
message. The recipients apply their 



magic decoder rings to the body of the 
message, and compare the result to the 
code that was received. If the) don't 
match, the message must be in error. To 
be efficient, the code should be small 
compared to the message body. Of 
course, the smaller the code, the more 
the possibility of aliasing, where two 
different messages can generate the 
same code. But with modern methods 
such as the CRC, this scenario is ex- 
tremely unlikely, as we shall see. 

The smallest code is a single bit. 
That's the idea behind the parity bit, 
which is a measure of the number of 
ones in the message's binary representa- 
tion — zero for an even number, one for 
an odd number. Since it's short, it's also 
easy to get aliasing, so parity bits only 
work for very small message blocks 
— typically one byte. 

Another choice is the checksum. It's 
a popular one, because it's so easy to 
understand and compute. We simply 
add all the bytes in the message as 
though they were binary numbers (ig- 
noring carries). Typically, the resulting 
sum is appended to the message as its 
twos complement, so that the recipient, 
adding the same characters plus the 
checksum, should get zero. Intel hex 
and Motorola S-record formats use ei- 
ther a 1- or 2-byte checksum. 

Finally, we have the CRC. As nearly 
as I can tell, it arrived on the scene in 
1961. The idea behind it is exactly the 
same as for the checksum: compute a 1 - 
to-4-byte BCC, calculated from the 
message body, and append it to the mes- 
sage. The only difference is the algo 
rithm embodied in the magic decoder 
ring. 

WHY USE A CRC? 

A little reflection should con- 
vince you that the reliability of 
any error -detection mecha- 
nism (due to aliasing) is a function of 
the size of the appended code. An N-bit 
code can only have 2 N unique values. A 
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single parity bit can only detect single 
(or any odd number of) bit errors. If the 
likelihood of multiple errors is low, it 
works fine. But if it's high, there's only a 
5() r ; chance that a parity bit will reflect 
the error. 

Similarly, a checksum or CRC of 
eight bits (one byte) can have only 256 
possible values, which means that, on a 
statistical basis, we have a 0.4% chance 
that a bogus message will slip through. 
Inversely, the reliability of the error-de- 
tection mechanism is 99.6%. For two 
bytes, the value is 99.9985%. Now, if the 
CRC also uses two bytes, you might 
think that it can't possibly be better 
than a checksum. So why bother with 
the more complex algorithm? 

That assumption would be true if 
transmission errors were truly random, 
but they're not. In the real world, two 
kinds of errors typically occur: random- 
bit errors and burst errors (in which sev- 
eral adjacent bits are garbled). The 
CRC shines in catching these two er- 
rors. Given the proper choice of algo- 
rithm, a 1 6-bit CRC can detect: 

■ 1 00% of all single-bit errors 

■ 1009! of all two-bit errors 

■ 10095 of all odd numbers of errors 

■ 100'.; of all burst errors less than 17 
bits wide 

■ 99.9969% of all bursts 17 bits wide 

■ 99.9985% of all bursts wider than 17 
hits ( the same as a checksum) 

lor extreme reliability, using 32 bits 
improves this performance even more, 
b\ five orders of magnitude! Those stat- 
istics are pretty impressive, which is 
what makes the CRC so popular. 

The nature of the checksum is such 
that errors tend to be localized, some- 
times changing only a single bit. Offset- 
ting or systematic errors (say, a stuck 
bit on the UART) can often be missed. 

B> contrast, any error in the message 
quick!) propagates into all the bits of 




The CRC is equally 
valid for small and 
large messages, 
which is why it is 
so popular and 
considered worth 
the extra 
computation 
required. 

the BCC, so the probability of two off- 
setting errors is virtually nil. In that 
sense, the CRC for a message is a bit 
like a hologram of a scene: the bits of the 
data are scattered through all the bits cf 
the BCC. For the same reason, the CRC 
is equally valid for small messages as for 
large ones. That's the reason the CRC 
method is so popular and considered 
worth the extra computation required. 

CLEARING THE FOG 

When I first asked someone to 
explain the CRC to me, I 
was told, "It's the remain- 
der of a polynomial division, modulo 
two." I was then given the generating 
polynomial: 

X 16 + x 1! + X 13 + X 7 + X 4 + X 2 + X + 1. 

Huh? What the heck does that mean? 
And what is x, anyway? A data bit? 
Shall I give it a value? 

A more meaningful way to under- 
stand what's going on with CRCs must 
exist. It's easier if we first digress into 
the related field of psuedo-random 
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numbers. Let's play a little game, of the 
kind'often seen in I.Q. tests or math puz- 
zle books. Look at this a sequence of 
numbers: 

1,2,3,4,5,6,7,8,9,10,11,12,13,14 

Quick! What's the next number in the 
sequence? 

If you didn't say 1 5, please move on to 
the next article. This one's not for you. 
For the rest of you, please give me the 
next number in this sequence: 

1,9,13,15,14,7,10,5,11,12,6,3,8,4,2 

Not so easy, is it? (The answer is one.) 
It's not supposed to be easy, because the 
second sequence is a set of what are 
called pseudo-random numbers. The 
"psuedo" part is because they are not 
really random. The sequence will repeat 
over and over forever. But by every oth- 
er measure of randomness you care to 
apply (average, standard deviation, and 
so on), the sequence is random. Hence 
the name. The sequence covers all the 4- 
bit integers, except zero. 

How did we get this sequence? In 
this case, the magic decoder ring is a 
hardware circuit, as shown in Figure 1 . 



It is a shift register, with one exclusive - 
0R gate added. Place any number in the 
sequence into the bits of this register, 
mentally cycle it, and you will soon con- 
vince yourself that it does indeed gener- 
ate the 15-number sequence. It's a 
source of psuedo-random numbers, bet- 
ter known as white noise, and you'll find 
one in every Nintendo game. Of course, 
in the real world, these generators use 
more than four bits. In general, an N-bit 
psuedo-random number generator can 
generate 2 N_I unique numbers before 
repeating. The — 1 is there because we 
can't allow the value zero. If the gener- 
ator ever gets all zero bits, no feedback 
can occur, so it will remain at zero. Un- 
fortunately, not just any old set of feed- 
back taps (the exclusive-OR gates) will 
do. For example, if the gate were al Bit 1 
instead of Bit 0, we would end up with 
three shorter sequences: 

a. 1, 10, 5,8,4,2 

b. 3, 11, 15, 13, 12,6 

c. 7,9, 14 

Now, you begin to see the trick}, part 
about this process. We want a maxi- 
mal-length sequence, and to do get it. 
the taps must be carefully chosen. And 
that's where the polynomials come in. 



Figure 1 

A hardware circuit. 
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POLY-CONFUSED 

My foray into the theory be- 
hind all this stuff led me 
deep into the bowels of group 
theory. I learned more than I care to 
know about Abelian groups and Galois 
fields. 1 sure won't burden you with all 
that stuff. You need only know that it's 
this theory that leads us into polynomi- 
als and polynomial division. It turns out 
that, for a maximal-length pseudo-ran- 
dom number sequence, you need a poly- 
nomial that's irreducible (one that can- 
not be factored). It's the polynomial 
equivalent of a prime number. Finding 
them is not easy. It's as hard as finding a 
large prime number, and complicated 
by the harder division process, but the 



For a maximal- 
length pseudo- 
random number 
sequence, you 
need a polynomial 
that's irreducible. 
It's the polynomial 
equivalent of a 
prime number. 

concept is straightforward. 

In the normal world of polynomials 
(not modulo two), the polynomial: 

x J + 2x + 1 

is reducible, because it can be factored 



into: 

(x+ l)(x+ 1). 

Similarly, x 2 — 1 can be factored into: 
(x+ l)(x- I). 

We look for factors of polynomials the 
same way as with integers: by trial and 
error, using division. We learned poly- 
nomial division (sometimes called syn- 
thetic division) in algebra class (re- 
member?). It's much like ordinary 
division, except that you have to write 
the polynomials with the highest order 
first, and use only the first terms in the 
divisor and dividend. If, for example, 
the highest order term in the dividend is 
x J and the divisor is x, the first term in 
the quotient has to be x 2 . From there, it's 
much like ordinary division: multiply, 
subtract, and bring down the remain- 
der. If the remainder is zero, the divi- 
dend is reducible. 

The polynomial arithmetic used for 
CRC theory is a little different. It uses 
modulo-two arithmetic. The reason is 
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simple: ordinary arithmetic doesn't per- 
mit the group properties that the math- 
ematicians need for their powerful 
methods to work. 

In modulo-two arithmetic, we don't 
have carries or borrows from any bit po- 
sitions. The rules for adding two bits 
are: 

+ = 
0+1 = 1 
1+0=1 

1 + 1=0 

Look familiar? It is also the truth table 
for a simple half-adder, or exclusive-OR. 
As it turns out, subtraction gives the 
same rules, so in this funny world of 



modulo two, addition and subtraction 
are the same. 

Already, we've cleared out one fog 
factor. The next time someone says 
"modulo-two arithmetic," just think 
"exclusive OR." Simple. Also, in this 
world twos and threes don't exist (1 + 1 



= 0, not 2), so the only coefficients poly- 
nomials can have are zero or one. Poly- 
nomial division in modulo two is as easy 
as it is in ordinary arithmetic, once you 
get used to the new rules. An example is 
shown in Figure 2. 

It looks straightforward, but writing 



Figure 2 

Modulo 2 division. 



X 2 + X +1 



X 2 + X + 1 ) X 4 + X 2 

X 4 + X 3 + X 2 



+ 1 



X J + 1 

X 3 + X 2 + X 



X 2 + X +1 
X 2 + X +1 

(remainder) 
A zero remainder means the dividend is factorable: 
X 4 + X 2 + 1 = (x 2 + X + 1) (x 2 + X + 1) 
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Introducing RTX -51 Operating System! 
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Figure 4 

Three representations of a hardware circuit. 



Figure 3 

The easy way. 
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Generating Polynomial = x 4 + x' + 1 
Feedback factor = 1 lb 

down all those polynomial terms gets 
tedious, especially if we're talking about 
1 6th-order polynomials! Fortunately, 
once I'd done this problem a few times, I 
finally figured out that it's not neces- 
sary to write the xs down at all 
— just the coefficients. Figure 3 shows 
the same division in this simplified 
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form. Looks a lot easier, doesn't it? In 
fact, it's simply binary division, but us- 
ing exclusive ORs instead of subtraction. 
Since it's binary, of course, you don't 
really need to perform a multiplication. 
At each step, we either subtract the divi- 
sor or we don't. We don't need to com- 
pare the two terms (we don't worry if 
one polynomial is bigger than the other. 
Since addition and subtraction are the 
same, the concept of "bigger" does not 
exist). We only have to look at the lead- 
ing terms. If they have the same order, 
we subtract. 

Now, we get rid of the second fog 
factor. From now on, when someone 
starts talking to you about polynomial 
division, you will know that what they 
really mean is ordinary binary division 
— modulo two. 

In Figure 3, each product to be sub- 
tracted is written down one place to the 
right, which is equivalent to shifting the 
dividend to the left. So, what we're real- 
ly talking about is shifting, then sub- 
tracting (or exclusive OR-ing) a constant 
value. But that's exactly what's going on 
in Figure l . The operations are entirely 
equivalent. 

We only have a couple of annoying, 
but minor, complications. First, the 
shift register shifts right, while the divi- 
sion operation shifts the dividend left. 
We'll just have to remember to reverse 
the bit order. 

Second, the division subtracts first, 
and then shifts for the next round. In the 
shift register, we look at the least signifi- 
cant bit (LSB) shift, then perform the 
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exclusive OR. The divisor is shifted one 
bit relative to its equivalent polynomial. 

It may not seem so, but at this point 
the fog is almost completely dissipated. 
We now have a "rosetta stone" that lets 
us translate between the three represen- 
tations. Consider, for example, the 
polynomial: 

x 4 + x 3 + 1 . 

In the binary form needed to do a divi- 
sion, this polynomial is 11001. The 
number has a one bit for every non-zero 
term, starting with the highest order 
(the highest and lowest bits will always 
be ones, by the way, for any useful 
polynomial.) 




You might well ask 
why I even bother 




polynomials, with 
their awkward 
representation 
and built-in 
confusion factor. 

To get the equivalent shift register, 
we first turn the number around, then 
sh if t it right one place, to get 1 00 1 . This 
number is the feedback factor that 
drives the generator. Place a tap at the 
entrance to every bit that has a one in its 
feedback factor. 

Alternatively, just remember that 
the left-hand bit of the shift register cor- 



responds to the lowest-order term in the 
polynomial; that is, x° or one. The three 
representations are shown together in 
Figure 4 (p.26). I advise you to cherish 
this figure. You will rarely see all three 
representations identified on the same 
figure, so it is literally a rosetta stone. 
With it, you need never be confused by 
polynomials again. 

You might well ask why I even both- 
er mentioning polynomials, with their 
awkward representation and built-in 
confusion factor. Good question. I wish 
I had a good answer. Tradition seems to 
be the only reason. The polynomial rep- 
resentation is good if you have to deal 
with the field theory to indentify a good 
polynomial. For the rest of us, it's com- 
pletely unnecessary, and only generates 
fog. Give me the feedback factor, or bet- 
ter yet, the whole equivalent circuit. But 
don't be surprised when others give you 
the polynomial form, because that's the 
way CRCs are normally defined. 

ON TO THE CRC 

Of course, the circuit shown in 
Figure 1 is not a CRC gener- 
ator, just a pseudo-random 
number generator. It cycles constantly, 
unchanged, because it doesn't recieve 
input. That's easy to fix, though. 

Remember that our pseudo-random 
number generator cannot deal with 
zero? That bothers some people, since 
clearing all the bits of a shift register is a 
common thing to do. The problem is 
easily fixed by inverting the output, 
which will still give us a maximal- 
length sequence, just a different one: 

0,9,4,11,5,2,8,13,6,10,12,15,7,3,1 

Now we can have a zero, but not a 14. 
No help for that. 

Next, let's get fancy. Suppose we re- 
place the inverter at the output by one 
more exclusive-OR gate (the missing one 
at x"), and let the data diddle it high and 
low. Boy, that should really confuse 
things! 

But that's precisely the concept be- 
hind the CRC algorithm. The idea is to 
get the effect of the data bits widely 
scattered throughout the BCC, which is 
what all those taps do. 

With that long buildup, we're now 
poised to look at true CRCs in all their 
glory. The most popular standards are 
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shown in Figure 5 (p.43). The CCITT 
algorithm is the international standard. 
The CRC-16 is most often used in the 
United States. The CRC-8 is pretty 



Listing 1 

The Serial _ CRC 

usesJtexOut; 

const Feedback = $8408: | CRC-CCITT | 
| $A001: CRC-16 | 
] $8000; LRCC-16 

var CRC: Word: 

| Process the CRC for a Single Byte 

Procedure UpdateCRC(B: Byte); 

var i: Integer; 

begin 

for i := 1 to 8 do begin 
if Odd(B) Xor Odd(CRC) then 

CRC (CRC Shr 1) Xor Feedback 
else 

CRC >« CRC Shr 1; 
B := B Shr 1: 
end; 
end; 

jSend a Message String [ 



much obsolete, and the CRC-l 2 is only 
used when bytes are six bits. 

As you can see, real CRCs differ 
from our toy one only in the number of 
bits — the concept is the same. For the 
record, however, the criteria for the gen- 
erating polynomial (feedback factor, 
for those of us in the know) is different. 
Rather surprisingly, the CRC gener- 
ators do not generate maximal-length 
sequences. In fact, the polynomials are 
deliberately chosen to be reducible by 
the factor x + l, because that happens 
to eliminate all odd-bit errors. The fact 
is, the polynomials are carefully tailored 



to get optimal error-detection out of the 
system. Don't worry about how they do 
it. Better them than us. 

I should mention a few points about 
how the data gets handled. From a 
mathematician's point of view, the en- 
tire message is considered to be a string 
of bits, each bit corresponding to a term 
in a humongous polynomial. So, from 
their point of view, we are dividing one 
long polynomial by another one. The 
BCC is the remainder. From our point 
of view, we are dividing two binary num- 
bers. In the real world, though, we know 
we're really sending messages a bvte at 




Procedure SendString(S: String); 

var i: Integer: 

begin 

for 1 := 1 to Length(S) do 
UpdateCRC(Ord(S[l])); 

end: 

| Send Message, Including CRC Bytes 

Procedure SendMessage(S: String); 

var OldCRC: Word: 

begin 

CRC : = 0; 

SendStrlng(S); 

OldCRC :- CRC; 

WrlteC CRC Computed is '); 

KordLn(CRC); 

UpdateCRC(OldCRC); 

UpdateCRC(01dCRC Shr 8): 



begin 

SendMessaget 'THE. QUICK . BROWN . FOX .0123456789 ' ) ; 

WordLn(CRC); 

ReadLn; 



You can start your debugging with this FREE demo simulator. You can load up 
to 512 bytes of code, assembler, C, or PL/M and do full debugging/simulation 
in assembly and source level. A great way to get started for FREE. , 

Fantastic for schools! Just call and we'll send It! / c./, ^ 

5 S?* 



The full-blown simulator is an extension of 
the DEMO. You can load up to 64K of 
code and use 64K of XOATA space. You 
can program an "external environment" 
to interact with your code to simulate your 
target system. The emulator is the hard- 
ware extension of the simulator! 
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The 30MHz real-time emulator has been 
the industry standard for years. With its 
complex breakpoint logic and advanced 
trace, nobody can beat it for performance. 
Plug-in or RS-232 configuration. All 8051 
derivatives are supported! 
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a time, and the standard convention for 
all data transmission is to send the least 
significant bit (LSB) first. It makes 
sense, then, to think of the LSB of the 
first byte as the most significant bit 
(MSB) of the long binary number that 
we're going to divide (or, equivalently, 
the highest-order term in the polynomi- 
al). That's the reason for the relation- 
ship between bit patterns and polynomi- 
al terms. It's confusing, because not 
only are these two items in opposite or- 
ders, but if we want to perform the divi- 
sion by hand (as a sanity check, for ex- 
ample), we have to invert the bits of 
every byte transmitted. 

To drive home that point, let's actu- 
ally perform such a division. The pro- 
cess is shown in Figure 6 (p.40). I've 
used a single-byte message, the ASCII 
character M. We'll use the CCITT 
code. To perform the division, we must 
append 1 6 zeros to the message. After 
all, the dividend has to be larger than 
the divisor! This step is not required 
when we do the CRC in hardware (or 
software). The circuitry takes care of 
that. 

Please follow along with this exer- 
cise. I know it's painful, but it will re- 
move all the mystery of the process. The 
polynomial is 1 7 bits long, so it leaves a 
remainder of 16 bits, as needed. We 
don't have to check to see if one term is 
larger than the other. Since addition is 
the same as subtraction in this number 
system, the concept of "larger," except 
as it refers to the number of bits, does 
not exist. We look only at the leading bit 
of each number, lining them up so 
they'll cancel, which corresponds exact- 
ly to the hardware implementation, 
where the exclusive OR is done strictly on 
the basis of the two leading (rightmost) 
bits. 

GETTING THE MESSAGE ACROSS 

Once we have the BCC, what do 
we do with it? The answer, of 
course, is to transmit it, since 
that's the mechanism the recipient uses 
to make sure the message is O.K. 

Remember that when a checksum 
(rather than CRC) is used, we usually 
transmit its twos complement, so the fi- 
nal sum is zero for an error-free mes- 
sage. The CRC works in a similar way, 
though we don't even have to comple- 
ment. Suppose that we've sent a mes- 



sage that the recipient has received. At 
this point, the contents of our BCC reg- 
isters should match. Now, we have to 



Table 1 

Test-case data. 

Data string CCITT SDLC 

'V 99E1 9666 

T 14A1 1B26 

'THE' 7D8D 44BE 

' THE .QUICK , BROWN , FOX , 0123456789 ' 7DC5 DF91 



send the BCC. As the LSB of the BCC 
arrives at the input, it should match the 
bit in the recipient's register, so the ex- 
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68331 , 68332, 68340 Developers: 

Don't Ignore 
Background Mode! 



If you're ignoring Background Mode, 
you're ignoring price/performance, 
ease-of-use, and non-intrusiveness 
in your debugging system. 

Motorola Doesn't. 

Motorola realized the benefits 
of on-chip debugging.That's 
why they designed Back- 
ground Mode into every 
CPU32 microcon- 
troller. 

Introducing 
the EST 
Series 300! 

The EST Series 300 
controls your CPU32 
target exclusively through 
a 5 MHZ Background Mode 
link. It's completely non-intrusive, 
since it doesn't require your target's 
RAM, ROM, interrupts, or serial port. 

Packed with 
Debugging Power. 

Of course, the EST series 300 delivers 
the features you need: simple and 
conditional breakpoints on RAM/ 
ROM, data breakpoints, stepping, 
tracing, view/modify registers and 
memory, and system diagnostics, 
at a fraction of the price of a full - 
blown ICE. 



Real-time Simulation. 

To get a head start on your software, 
the EST Series 300 builds in a CPU32 
controller and 128K of simulation 
RAM. Or, our Background Mode 
system works with your EVS 
board, right out of the box 

C Source Level 
Debugging. 

EST has ported 
Intermetrics' 
XDB5.0 
to the 
Series 3(H). 
XDB delivers 
,i proven 

windowed 
interface, complete 
source and symbolic 
information, C level tracing, 
and powerful macros 

Try Background Mode. 

Just call us, and we'll send you an 
EST Series 300 for a free 1 4 day trial. 

No obligation. No Risk. 

(617) 828-5588 

Embedded 
Support 

Tools Corp. 'WYVvvyyVyVt- 
10 Elmwood St., Canton, MA 02021 
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elusive OR is zero. Nothing gets fed back 
during the shift. If no errors have oc- 
curred, the same will be true for every 
succeeding bit. No data is ever fed back, 
so the BCC just gets shifted out, leaving 
a zero value. In this case, zero is the 
winning score! 

PROGRAMMERS DO IT IN SOFTWARE 

Up until now, I've emphasized 
the hardware aspects of the 
CRC generator. As a matter 
of fact, that's the way the CRC was ori- 
ginally used. Today, it's very often done 
in software, which will be our focus for 
the remainder of this article. 

A straightforward translation of the 
algorithm to software is shown in List- 



We're not really 
sending the 
message 
anywhere, so I 
added a little 
debug output to 
give the value of 
the computed CRC. 

ing 1 (p.31), written in Turbo Pascal. 
The bit-by-bit update of the shift regis- 
ter is done verbatim by procedure Upda- 
teCRC. As you can see, it's pretty simple 
stuff. Following the circuit exactly, we 
exclusive OR the low-order bits of the 
BCC and data, and use the result to de- 
cide whether or not to feed back into the 
taps. The only difference between these 
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1 6-bit CRCs is the tap positions, which 
are embodied in the variable FeedBack. 

The SendString procedure sends a 
string of bytes. The SendMessage proce- 
dure initializes the BCC and sends its 
final value. We have to save the value, 
since it will continue to be updated as its 
value is sent. 

We're not really sending the mes- 
sage anywhere, so I added a little debug 
output to give the value of the computed 
CRC. The final value printed should al- 
ways be zero. 

By the way, one of the things sorely 
needed in working with this algorithm is 
some test-case data. Fortunately, Greg 
Morse was kind enough to give us some 
test cases, which I've supplemented a 
bit in Table 1 (p.33). They're an invalu- 
able aid for debugging. 

A TABLE-DRIVEN CRC 

The verbatim, bit-by-bit algo- 
rithm gets the job done and is 
fine for most applications. But 
it turns out that we have a better, and 
much faster, algorithm. Since we're 
really sending stuff in bytes rather than 
bits, wouldn't it be nice if we could gen- 
erate the new BCC for a byte in one 
step? Because of the MixMaster nature 
of the CRC algorithm, it's certainly not 



Listing 2 

A table-driven algorithm. 

1 Initialize the CRC Table for a bytenise CRC. 
This procedure »orks for any CRC code. If 
ProcessByte is adjusted as needed. 

Procedure MakeTable: 
var 1: Integer: 
begin 

for l := to 355 do begin 

CRC := 0: 

ProcessByte(i): 
Table[i] : = CRC ; 
end: 
end: 

Send a single byte using table- 
driven algorithm 

Procedure SendByte(B: Byte): 
begin 

CRC : = (CRC Shr 8) Xor Table[B Xor Lo(CRC)]: 

end: 



The 8-Bit 
Solution 
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obvious that we can. To see how it's pos- 
sible requires one last exercise in pain. 

Let's try to follow the progress of an 
arbitrary byte through the system. Just 
prior to the first shift, the LSBs of the 
BCC and the data byte are available at 
the inputs to the tap. If we define: 

X = DXorLo(C). 

where Lo(C) is the low byte of the BCC, 
then this value will be the LSB of X, say 
X . As the data is shifted, X will be fed 
into every stage that has a tap. In any 
given stage, all the terms in a given col- 
umn are to be exclusive ORed together. 

This same process takes place for ev- 
ery bit transmitted. The final state of 
the register after the eighth shift is 



Listing 3 

table 



| This procedure creates 

the table for a bytenise CRC. The 

algorithm Is specific to the CCITT 

CRC. Other codes can be done In a 

similar manner. 

Procedure MakeTable; 

var I: Integer: 

Z: Byte; 
begin 

for 1 :- to 255 do begin 
z := 1 Xor (1 Shi A); 
T«ble[l] :- (z Shi 8) 
Xor (z Shi 3) Xor (z Shr 4); 



Listing 4 

(C without a 



| This Procedure Permits Bytewlse 
CRC without the Need for a table. The 'table 
entry" Is built "on the fly." Note that the 
algorithm is specific to the CCITT CRC. 
Other codes can be done In similar manner. ) 

Procedure UpdateCRC(B; Byte); 



B :■ 8 Xor Lo(CRC); 
B :- B Xor (B Shi 4); 
CRC ,« [CRC Shr 8) Xor (B Shi 8) Xor 
(B Shi 3) Xor [B Shr 4): 
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Price and performance are no 
longer mutually exclusive. Softaid's 
8-bit UEM Emulators find bugs fast. 
And only Softaid has the Fiber-Optic 
Link that reduces download time to 
virtually zero. Spend a lot 
less time waiting, and a lot 
more time debugging. 

All of Softaid's UEM 
Emulators include built-in 
performance analysis and 
a source-level debugger ■■■■■■■ 
for C, C++ and PIVM. Our real-time 
Memory Access Monitor instantly 
captures "stack creep" and those 
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programs that mysteriously "wander 
off." In C or assembly, the UEM 
automatically tracks the MMU. 

Collect real-time trace data with 
pre, post, or center triggers. Display it 
in C source or 
intermixed with the 
disassembled trace 
data. Or, use your own 
clock to collect logic 
analyzer data. 
Is there a better 
solution than Softaid? At $5,495, this 
may be the best 8-bits of advice you 
ever get. 
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shown in Figure 7 (p. 44). The dotted 
line is to emphasize that the resulting 
BCC really consists of two parts: 

■ The high byte of the original BCC, 
shifted down into the low-byte position. 

■ The rest of the result, which depends 
only on the value of X. 

Now, whatever value X has, it is, after 
all, only a byte, so it can only take on 256 
possible values, which suggests that we 
can precompute the value and store it in 
a table. The table, of course, is constant, 
so it can be precomputed at initializa- 



Listing 5 

The 



| The XMODEM Algorithm shifts left ] 
) Instead of right. This Impacts most of the ] 
j procedures. | 

{ Bytenlse. table-driven algorithm for XMODEM | 

Procedure SendByte(B: Byte); 
begin 

CRC := (CRC Shi 8) Xor Table[B Xor Hi(CRC)]; 



| Table Builder for XMODEM | 

Procedure MakeTable; 
var 1: Integer, 

Z: Byte; 
begin 

for 1 ;- to 255 do begin 
z ;■ 1 Xor (1 Shr 4); 

Table[l] :» z Xor (z Shi 5) Xor (z Shi 12); 



| Message Protocol for XMODEM. Note the two 
j null bytes, and the »ay the BCC Is sent. 



p(S; String); 
var OldCRC; Kord; 
begin 

CRC ; = 0; 

SendStrlng(S); 

OldCRC :» CRC; 

HrltefCRC Computed Is '); 

WordLn(CRC); 
SendByte(OldCRC); 
SendByte(Hl(01dCRC)); 









Stop Wasting 
time&money 

BSO/TASKING'S new toolkit 
for developing software for 
the 68000 family, called 
TASKTOOLS" beats all others 
on the market today. Check out 
these features and benefits. 

C COMPILER 
•ANSIC 

• Highly optimized code 

• Reentrant code 

• Direct control of I/O 

• Interrupt handlers may be 
written in C 

• Floating point support 
•68040 and 68332 support 

CROSS VIEW" DEBUGGER 

• All major emulators supported 

• Multi-window interface 

• Code & data breakpoints 

• Source level tracing 

• Stack tracing 

• I/O simulation 
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Benefits 

TASKTOOLS" offers you the 
following benefits: 

■ Reduced code size 

• Increased productivity 

• Great documentation 

• Hot line support 

• For PC, Sun, Vax, HP, Apollo, 
IBM & DEC RISC 
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Other Processors 
With Similar Support 

■ Motorola 68HC11 
•Intel 80X86 

• Intel 8051 & derivatives 
•TMS320C25 
•Siemens 80C166 
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1-800458-8276. 

Outside U.S.A. 617-8947800. 
Fax 617-894-0551. 
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tion time or loaded as a constant. Then, 
to process the CRC, all we have to do is a 
couple of Xor's and a table lookup. The 
processing algorithm goes as follows: 

■ Compute X = DXorLo(C) 

■ Use X as an index into the table, fetch 
T[X] 

■ Compute the new CRC as: 

T[X]Xor(C>>8) 

It's really quite simple. We still have to 
create the initial table. It turns out not 
to be difficult, though. Suppose that the 
initial BCC were zero, and we process 
the byte X, bitwise. Then, the result 
should be just what we're looking for, 
since all the C bits will be zero. To gen- 
erate the table, all we need to do is pro- 
cess the integers from zero through 255, 
using the bitwise algorithm. 

The results are shown in Listing 2 
(p. 34). Again, the only significant dif- 
ference between the CRC algorithms is 
in the values used for Feedback. Now, you 
might think we have gone about as far 
as we can possible go with the CRC al- 
gorithm, but we can still make some 
improvements. 

The problem is that grotty bitwise 
table computation. We end up having to 
provide a bitwise and bytewise CRC 
routine, using the first one just to create 
the lookup table. Aesthetically, that's 
not so pleasing. 

Even though the bit patterns of the 
XjS are complex, we can see a pattern, 
and it turns out that the table entries 
can be generated with just a few shifts 
and exclusive ORs. A word of warning, 
though — this approach makes the Make- 
Table procedure algorithm-specific. The 
bit patterns will differ depending upon 
the polynomial used. The code shown in 
Listing 3 (p.37) is for the CCITT poly- 
nomial. The others are similar, and the 
rules are given in Table 2 (p.45). 

Finally, in some cases (single-chip 
controllers, for example), speed is not as 



Suppose that the 
initial BCC were 
zero, and we 
process byte X, 
bitwise. The result 
should be what 
we're looking for, 
since all the C bits 
will be zero. 

important as program size. Our 512- 
byte table may be too much for such 

Figure 6 

Hand check of CRC. 

Input Message ■ 'M' = 4Dh = 0100110b 



BCC = 1001 1001 1110 1000 = 99E8h. 



systems. 

In this case, we can still get the bene- 
fits of the bytewise approach, by com- 
bining the table-build and table-lookup 
steps. In effect, we are building each ta- 
ble entry on the fly, each time we need it. 
The code for this procedure is shown in 
Listing 4 (p.37). 

DETAILS AND GOTCHAS 

That pretty much wraps up the 
basic concepts of CRC process- 
ing. However, we still have 
some minor nits to pick, which can turn 
out to be major roadblocks if you're 
caught unawares. 

First of all, almost everyone who im- 
plements the CRC algorithms follows 
the rules, but every once in awhile you 
run across one that doesn't. We've al- 
ways shown the shift registers shifting 
right, and corresponding to the low-bit- 
first rule. But it doesn't have to be done 



Reverse the bit pattern, and append 16 zeros to get the dividend: 
1011 0010 0000 0000 0000 0000 

Generating Polynomial = x' 6 + x' 2 + x 5 + l =1 0001 0000 0010 0001 (divisor) 
Divide using bitwise exclusive or: 

Quotient (discarded) — > 1011 1001 

1 0001 0000 0010 0001 ) 1011 0010 0000 0000 0000 0000 
1000 1000 0001 0000 1 



11 1010 0001 0000 100 
10 0010 0000 0100 001 



1 1000 0001 0100 1010 
1 0001 0000 0010 0001 



1001 0001 0110 1011 
1000 1000 0001 0000 1 



1 1001 0111 1011 1000 
1 0001 0000 0010 0001 



Remainder (BCC) 1000 0111 1001 1001 

Reverse bit pattern again to get BCC in its usual form: 
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that way. The CRC will still work, 
whether the data is sent LSB first, first 
byte first, or not. It's just that nobody 
will be able to read the message! 

The most notable violator is in the 
XMODEM/CRC algorithm. When 
Ch uck Forsberg implemented this code, 
he found that on the 8080 it's a lot easier 
to shift registers left than right. Basical- 
ly, the XMODEM algorithm isCCITT 
done backwards. The bytes are pro- 
cessed in order and, of course, sent LSB 
first (since LSB is controlled by hard- 
ware), but the CRC is done as though 
the bytes were being sent MSB first. Be- 
cause the XMODEM code is so unique, 
the table-driven version of it is included 
in Listing 5 (p.39). The XMODEM al- 



gorithm also has a couple of other pecu- 
liarities: two null bytes are processed 
after the message is sent. I suppose 
Forsberg was thinking of those added 
bits in the manual division process. 
They are not needed, but since he uses 
them, you need to also. Since they are 
there, the BCC will not come out to be 
zero when the transmitted BCC is pro- 
cessed, so the two are compared. XMO- 
DEM sends the BCC high byte first. 



Another gotcha lies in the SDLC 
/HDLC algorithm used by IBM. It is 
basically the CCITT algorithm, but 
with a critical difference: instead of ini- 
tializing the BCC to zero, in SDLC it's 
initialized to FFFFh, to catch any un- 
wanted null bits preceeding a message. 
(With the standard CCITT version, the 
BCC never changes from zero until the 
first non-zero bit is encountered.) 

In SDLC, the resulting BCC is also 



Figure 7 

Result of processing eight data bits. 

Initial value 

C, 5 C )4 C13 C[2 C 1 1 C| C9 Cg C7 C 6 C5 C4 C3 C2 Ci C 



Result after eight shifts 



C15 C14 Ci 3 C12 Cm C]o C9 Cg 



X7 Xs X5 X4 X3 X2 X| Xq X7 X5 X5 X4 

X7 Xg X5 X4 X3 X2 Xj Xo 
X3 X2 X] Xo X3 X2 X] Xq X3 X2 X] Xq 
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converted to its ones complement before 
it's transmitted. Therefore, the end re- 
sult is not a zero BCC. Instead, it turns 
out to be a constant but non-zero value 
dependent only upon the polynomial. 
For SDLC, the magic number is F0B8h. 

One last point: we've talked about 
the tradeoff between speed and size, and 
often speed is quite important. The al- 
gorithms used in XMODEM can keep 
up with 9600-baud transmission, which 
is not bad at all. However, a better ap- 
p7oach is not to ask them to try. If you 
are transmitting bytes without facilities 
for intermediate storage, you have no 
choice but to process as you transmit 
and/or receive. But usually, the data is 
copied into a block buffer anyway, be- 
fore it's transmitted. So, the best ap- 
proach is to precalculate the BCC from 
the data in the buffer and append it to 
the buffer before you send it. That way, 
once the block transmission starts, it 
can run at the full bandwidth of the data 
link. Similarly, on the receiving end, it's 
best to receive and buffer the data, then 
process it between blocks. 

WINDING DOWN 

That about wraps up the story for 
CRCs. I hope you liked it. It's 
fun to work with them, and 
knowing how may turn out to be impor- 
tant to you someday. The bytewise algo- 
rithms we've covered are pretty much 
the state of the art. 

Just remember: approach this sub- 
ject with care. If you're working with 
someone to implement a CRC, make 
sure that all parties agree precisely 
what the algorithm is. Each time I think 
I've seen every possible variation, along 
comes another one — some of them just 
plain wrong. Remember, if anything is 
done differently at the sending and re- 
ceiving ends, the CRC will declare an 
error, and you'll end up tearing your 
hair out trying to figure out the prob- 
lem. The test-case strings should help. 
Good luck. 
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Table 2 

Bytewise algorithms. 

CCITT and SDLC/HDLC 

Build Table: 

z := i Xor (i Shi 4) 

Table[i] (z Shi 8) Xor (z Shi 3) Xor (z Shr 4) 
Update CRC: 

CRC := (CRC Shr 8) Xor Table[Data Xor Lo(CRC)] ; 

XMODEM 
Build Table: 

z : = i Xor (i Shr 4) 

Table[l] := z Xor (z Shi 5) Xor (z Shi 12) ; 
Update CRC: 

CRC := (CRC Shi 8) Xor Table[Data Xor Hi(CRC)] ; 

CRC-16 
Build Table: 

if Parity(i) then 

T := $C001 
else 

T := 0; 

Table[i] := T Xor (i Shi 6) Xor (i Shi 7): 
Update CRC: 

CRC -.= (CRC Shr 8) Xor Table[Data Xor Lo(CRC)] : 
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